autobahn mempool#3522
Conversation
PR SummaryHigh Risk Overview The new mempool buffers txs into lane blocks (count/byte/gas caps), blocks inserts when full, enforces EVM nonce order, and prunes after local lane execution via Reviewed by Cursor Bugbot for commit a081eb7. Bugbot is set up for automated code reviews on this repo. Configure here. |
|
The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #3522 +/- ##
==========================================
- Coverage 59.05% 58.16% -0.90%
==========================================
Files 2205 2129 -76
Lines 182317 173645 -8672
==========================================
- Hits 107672 100996 -6676
+ Misses 64945 63669 -1276
+ Partials 9700 8980 -720
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
| delete(m.evmNonces, addr) | ||
| for _, x := range m.blocks { | ||
| delete(x.evmNonces, addr) | ||
| } |
There was a problem hiding this comment.
Nonce reset misses open block's evmNonces map
Low Severity
When pruneMempool detects a nonce mismatch and resets tracking for an address, it iterates over m.blocks to delete the address from each sealed block's evmNonces. However, m.nextBlock (the currently-open, not-yet-sealed block) is not included in this cleanup. Since m.nextBlock is a separate field and not part of m.blocks, any stale evmNonces entry for the affected address persists in the open block. This inconsistency means the open block carries stale nonce expectations that the sealed blocks were explicitly cleaned of.
Reviewed by Cursor Bugbot for commit 2161b70. Configure here.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.
There are 3 total unresolved issues (including 1 from previous review).
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit a081eb7. Configure here.
| go func() { _, _ = env.Mempool.CheckTx(ctx, req.Tx) }() | ||
| if giga, ok := env.gigaRouter().Get(); ok { | ||
| go func() { _, _ = giga.Mempool().InsertTx(ctx, req.Tx) }() | ||
| return &coretypes.ResultBroadcastTx{Hash: req.Tx.Hash().Bytes()}, nil |
There was a problem hiding this comment.
BroadcastTxAsync silently drops txs under backpressure
Medium Severity
In the autobahn path of BroadcastTxAsync, InsertTx is launched in a detached goroutine using the HTTP request's ctx. Unlike the old CheckTx (which returned near-instantly), the new InsertTx blocks when the mempool is full. When the handler returns immediately after go func(), the request context is cancelled, causing the blocking InsertTx to fail silently. Under backpressure, transactions submitted via BroadcastTxAsync are effectively dropped instead of queued.
Reviewed by Cursor Bugbot for commit a081eb7. Configure here.
| // Seal the payload if needed. | ||
| if toProduce == m.next { | ||
| m.PushBlock() | ||
| } |
There was a problem hiding this comment.
Missing ctrl.Updated() after PushBlock in producer loop
Low Severity
When the producer's Run loop seals a partial block via m.PushBlock() after the BlockInterval timeout, no ctrl.Updated() call follows. This means InsertTx callers waiting on !m.IsFull() won't be woken up even though m.nextBlock is now empty (which makes IsFull() false). They remain blocked until the separate pruning goroutine eventually calls Updated() after execution, adding unnecessary latency to transaction insertion.
Reviewed by Cursor Bugbot for commit a081eb7. Configure here.
1 participant
Mempool constructed specifically for autobahn tx lifecycle: